Workflow process management is a technology that provides the ability to define and automate the flow of work through an enterprise in order to accomplish business tasks. The business tasks may be first modeled as workflow processes, which are then automated by workflow management systems (WFMSs). Commercially available WFMSs, such as the Hewlett-Packard Changengine, are capable of supporting a large number of workflow processes in an efficient, reliable and secure manner.
A "workflow process" is a coordinated set of process activities that are connected in order to achieve a common business goal. Thus, a workflow process is typically a sequence of process activities. A "process activity" is a logical step or description of a piece of work that contributes to the accomplishment of the workflow process. A process activity can be executed manually or automatically. Each process activity is related to a work item and a workflow participant. A "work item" defines the work that is to be processed in the context of the related process activity and is performed by one or more workflow participants. A "workflow participant" is either a person that performs the work item for a manual process activity or a computer-based application that performs a work item for an automated process activity. "Resources" are defined as workflow participants and the objects that they utilize in performing work items.
A workflow participant can usually perform work items for more than one process activity. In the reverse, work items can generally be performed by more than one resident workflow participant. A workflow participant often requires use of or access to other resources when performing a work item. For example, a person that prints a document requires use of a printer. Workflow participants together with the objects that are used by the workflow participants are external resources for a WFMS.
One of the important features of modern WFMSs is the realization of dynamic resource allocation, which provides resource independence to business processes. Thus, a workflow process does not need to be modified when underlying resources change. Moreover, resources are more efficiently utilized. A modern WFMS includes a resource manager, which allows run time resource allocation. The resource manager provides a resource model for process designers to use for resource specification at process definition time. The model is an abstraction of the physical resources and shields the process designers from the detailed specification of the required resources. The resource manager also manages workflow resources (e.g., keeps track of status of resources) and assigns workflow resources to business steps (i.e., process activities) when requested to do so by a workflow execution engine.
One problem with resource management in WFMSs relates to efficiently assigning resources to process activities at process execution times when there are a number of workflow processes being executed simultaneously. Workflow resource management is concerned with: (1) keeping track of resource status (e.g., availability and load) and (2) finding eligible, available, and hopefully least loaded resources for workflow activities when needed. The resource management problem is not trivial in many workflow environments, since workflow resources are distributed, the number of work-flow resources are large, and resource status changes frequently.
Traditional approaches to workflow resource management have been to either manage distributed resources globally at a central site or to manage the distributed resources locally. Under the global management approach, the distributed resources are under control of a global resource manager (GRM). The resources are registered to the GRM, with an identification of the roles that the individual resources can assume. The GRM is responsible for keeping track of the status of each of the registered resources. The main advantage of the global management approach is that resource assignment is relatively easy and efficient, since all resource information is contained at a single site. However, this approach incurs huge overhead in keeping track of status of remote resources. The approach is impractical in many real workflow environments for a number of reasons. First, the number of remote resources can be large. For example, in the workflow process of providing employee expense reimbursement, a large corporation may have more than 10,000 employees as workflow resources. It is extremely difficult for the GRM to keep track of load information about remote resources, since the information changes frequently. Second, resources of a large enterprise usually belong to different organizations. Workflow resources at different organizations and locations are often managed by different systems independently. These external resource systems can be heterogeneous with respect to resource models, query language and communication protocol. Third, process designers need different views of workflow resources at different levels. Most business processes only involve local resources. On the other hand, there are cases in which an enterprise-wide view of all workflow resources is needed.
In the local management approach, resources are managed by multiple, distributed local resource managers (LRMs). Each LRM has all status information regarding resources and has full control over resources at its site. The approach may include utilizing a GRM at a central site to maintain role information for all the resources and their managing LRM, but resource management system relies on individual LRMs for resource assignment when a work item is to be performed. The local resource management approach avoids the huge overhead of keeping track of dynamic changes of resources by managing them locally. However, this approach makes run-time resource assignment difficult and sometimes inefficient.
A system that overcomes some of the problems of the two traditional approaches is described in U.S. Pat. No. 5,826,239 to Du et al., which is assigned to the assignee of the present invention. The system provides distributed resource management in a computer network that includes multiple computers operating under control of a WFMS which manages available resources to carry out a workflow process. Resources are grouped according to shared sets of capabilities. Each resource group includes at least one resource. One or more computers in the network stores a GRM and data to define the resource capability of at least some of the groups, and further stores the resource status for each group for which it has the data relating to resource capability. Preferably, each computer that does not store a GRM stores an LRM for at least one of the groups and includes data that defines the capability and the status for each resource in each group to which it is assigned. Thus, instead of doing resource management in one step, either at a central site (in the global management approach) or at remote sites (in the local management approach), the approach of Du et al. first checks the availability of resource groups at a central site and then selects (at remote sites) specific resources from the group.
FIG. 1 is a schematic view of a simplified workflow process. A workflow process is a description of sequencing, timing, dependency, data, physical agent location, and business rule and authorization policy enforcement requirements of business activities needed to enact work. An upper portion 10 of FIG. 1 represents the activities that are required to implement the workflow process, while the lower portion 12 represents the resources for executing the activities. The example is one in which a claim for payment is processed. In a first step 14, the claim is submitted. The enterprise that is represented in this example utilizes an employee 15 to receive the claim, but automated resources may be used by different enterprises to execute the step. In step 16, the claim is checked to determine whether it meets business requirements. The claim is also checked to determine the class 17 in which it is fit under procurement rules of the enterprise. The employee 15 enters the information from the claim into a computer 18. The computer may be one of a number of computers that are interconnected to form a network. Each computer is managed and controlled by a user or by a machine. The coordination of the computers within the network can be accomplished by computer software, such as object-oriented software. The determination of the class in activity 17 is part of the process management rules 19 of the enterprise in the execution of the workflow process. Workflow process activity information, such as resource data and rules, can be stored in a database on a centralized WFMS server, not shown, which is accessible by the computers 18 via a bus line. Alternatively, each computer may store the resource data and the rules.
The determination of the class at process activity 17 may merely be a determination of whether the submitted claim can be handled using petty cash or requires an authorization of a manager, as shown at activities 20 and 21. This determination may be based merely upon the dollar amount identified in the claim. If insufficient information is contained within the claim, the claim is resubmitted, as indicated at activity 22. The steps 17, 20, 21 and 22 are executed in computer software under control of the process management rules 19. If the claim can be processed using petty cash, the procedure ends at activity 23 by paying the persons who submitted the claim. The resource for executing this activity may be an employee 24 or may be an automated device. For claims that require manager authorization, an activity 25 of recognizing the authorization is executed in computer software 26. For example, electronic signatures may be required in order to allow automated processing.
A claim which does not include the required authorization may be rejected at activity 27, so that the process is completed at activity 28. Resources for implementing these activities may be a printer 29 that outputs an explanation to the person that submitted the claim and a delivery system 30 that may include mailing or electronically transmitting the explanation to the person that submitted the claim.
When the required authorization is provided for the submitted claim, the appropriate activity 31 is to notify the payroll department, which can initiate the payment process at activity 32. Notification may be provided by a facsimile device 33. The initiation of the payment process may require a handoff 34 of the processing to a second workflow process that requires additional resources.
In the operation of the WFMS of Du et al., the GRM is invoked with a request for a specific activity, such as a request for the facsimile device 33 to transmit notice to the payroll department in order to execute activity 31. The GRM responds by checking the stored capabilities and the status of the resource groups, selecting one of the resource groups having the capability to perform the specific activity and having the status that enables the group to do so, and forwarding the request to the LRM of the computer that is specific to the selected resource group. The LRM of the specific computer can respond to the request by selecting one of the resources (e.g., one of the available facsimile devices) in the selected resource group to perform the specified activity and by assigning the activity to the selected resource. The LRM then updates the stored status data of the resource and forwards the updated status data to the GRM.
While the approach of Du et al. provides a significant reduction in operation overhead without introducing long delays in run-time resource assignment, further improvements are desired. Specifically, what is needed is a method and system for providing resource management such that the flexibility and the scalability of implementation are enhanced. What is further needed is such a method and system that allow different views of workflow resources at different levels of an enterprise, while still providing an enterprise-wide view of all workflow resources.